Pony RT options passing #155
Conversation
alexsnaps
changed the title
|
|
||
| # Detailed design | ||
|
|
||
| Building upon [RFC-0064](0064-llvm-cli-opts-integration.md), as we probably should avoid introducing a new pattern, the proposal is to have a single option, namely `--pony_opts`, to pass all options as a single, comma seperated string, for the runtime to consume, e.g.: |
There was a problem hiding this comment.
--pony-opts might be more idiomatic for CLI than --pony_opts?
That is, dashes are probably more idiomatic than underscores.
SeanTAllen
added
the
status - final comment period
|
Hi @alexsnaps, We discussed this at sync. No one has strong feelings about what should replace what we have (in terms of your alternatives) beyond the "-" instead of "_". We think either of your alternatives is better than what we have so we are good with moving forward with them. Thank you for this RFC. We have put it into a final comment period and will be voting on it soon. Can you update to change the |
SeanTAllen
changed the title
|
Does it make sense to have a call to provide the software author the ability to:
|
|
@redvers What options do you imagine the software author would want to disable? What does "disable" mean to you? Can you give some scenarios you are thinking of? |
|
|
Looks good to me. I agree on the Personally, I think the namespacing alternative is superior to the environment variable route. The Pony philosophy includes Correctness as its first tenet and Consistency as the second to last. Managing environments in addition to executables is a hassle and decreases the likelihood of correctness, and running without the same environment would break consistency. A given program should run correctly and consistently wherever one chooses to run it. My thought on a sort-of halfway to using environment variables (where one gets to always use their preferred defaults) is to bake the desired runtime defaults into the executable via compile-time options. People would get to set their preferred defaults when they compile the program, but it executes with the same semantic defaults no matter where it is run despite the environment. Configuring these personal preferences might be a good feature for the dependency manager |
|
Removing from final comment period until the |
jemc
removed
the
status - final comment period
Pony runtime tweaks through arguments
The existing
--pony*arguments are provided to theponycoutputted executable--ponyhelpas the input grew--pony*arguments are not exposed throughEnv.args(which I think is a wise decision, I only see pros to it, but in case some think this might be revisited as part of this, I guess it could)Issues with the existing
--ponythreadsto--ponymaxthreads, an upgrading user could miss this change, and this would just be silently ignored. In this very case resulting in ignoring the user specified value and falling back to default. Also resulting in the old argument now being exposed to hisEnv.argsThis RFC tries to address the above. Mostly trying to get the ball rolling again. I've had some personal things going on that came in between me and this…
Moving forward I'll start implementing and filling the
Detailed designsection in. But wanted to get this discussion going again… in a more "formal" way than on Tulip. So please have at it! 🙇Formatted version here